Software Case Marking Language Definition

ion Level Link type Possible direction(s) of traversal (Inter-level) IsAllocatedTo both Satisfies both Abstraction (without subtypes) both Implements both Requirements ConflictsWith none Constrains source← target DependsOn source→ target DerivesFrom source→ target Elaborates source→ target IsSimilarTo both MakesPossible source← target Operationalizes source← target Fulfils both InvocationRelationship source→ target Participation none Usage none Architecture & Dependency (without Abstractions) client→ supplier Design Realization client→ supplier Table 5.2: Traceability link types considered in slicing approach Architectureand design-level link types • Dependency: If the slice already comprises the client NamedElement, the supplier NamedElement shall also be included. The supplier NamedElement is needed by the client NamedElement. Note that this is not true for links of Dependency’s Abstraction subtype, as these denote inter-level links (see above). • Realization: If the slice already comprises the client NamedElement, the supplier NamedElement shall also be included. The supplier NamedElement is implemented by the client NamedElement. 5.2.4 Taking into account other structures Besides traceability links and nesting relationships, there are other structures which have to be taken into account by the slicing approach. For instance, a Generalization relationship between two Classifiers denotes that the specialised classifier inherits the properties of the generalised classifier. Thus, if a slice comprises the former, the latter has to be included, too. As with nesting relationships, a comprehensive overview would be out of scope in this document. Therefore, table 5.3 only contains some examples. IST-2006-033596 ReDSeeDS: Requirements Driven Software Development System page 23 Software Case Marking Language Definition – D4.3 Partial software cases ver. 1.01 21.11.2007 Abstraction Level Structure Possible direction(s) of traversal Architecture & Generalisation specific→ general Design PackageImport importingNamespace→ importedPackage PackageMerge receivingPackage→ mergedPackage Table 5.3: Other structures considered in slicing approach Another structure to be considered is the caller/callee relationship between two methods on the code level.ion Level Structure Possible direction(s) of traversal Architecture & Generalisation specific→ general Design PackageImport importingNamespace→ importedPackage PackageMerge receivingPackage→ mergedPackage Table 5.3: Other structures considered in slicing approach Another structure to be considered is the caller/callee relationship between two methods on the code level. 5.2.5 Summary of the slicing approach This section summarises the various aspects of the slicing approach presented in sections 5.2.1 to 5.2.4. First, a slicing criterion containing one or more elements of a software case has to be selected. It constitutes the basis for computing the slice, i.e. the slice will contain all elements of a software case which are related to the slicing criterion. In ReDSeeDS, the slicing criterion will be a set of elements from the requirements level of a past software case which is similar to a requirements specification of a current software case. Starting from the slicing criterion, the slice contains all elements reachable by traversing • nesting relationships between elements exemplified in table 5.1, • traceability links as given in table 5.2, and • other relationships as exemplified in table 5.3. Furthermore, the heuristic on traversing a specific inter-level traceability link only once has to be obeyed (see also section 5.2.1). 5.2.6 Computation using GReQL The slicing approach described in sections 5.2.1 to 5.2.5 operates on the abstract syntax graphs of software cases and suggests traversal as a means of accessing their elements. IST-2006-033596 ReDSeeDS: Requirements Driven Software Development System page 24 Software Case Marking Language Definition – D4.3 Partial software cases ver. 1.01 21.11.2007 In the course of the ReDSeeDS project, JGraLab emerged as the technology of choice for the fact repository containing past software cases (see also [BER+07]). It is capable of storing their abstract syntax graphs as TGraphs [EF95] and offers a means to traverse them as needed by the slicing approach. An equally powerful, but more concise way of retrieving information from the repository is querying. Querying can be performed by employing the Graph Repository Query Language (GReQL), which is closely integrated with JGraLab. As an example, consider the following query realising the retrieval of all elements of a software case connected to a slicing criterion via traceability links: from sc : V{Requirement}, v : V{SCLElement} with sc.uid = "Req42" and sc <->{TraceabilityLink}* v report v end This simple GReQL-query returns all vertices v of type SCLElement which are connected to the vertex sc of type Requirement with the attribute uid set to Req42, constituting the slicing criterion. 5.3 Sample computation of a partial software case This section describes an example how to slice a partial software case out of an existing software case. This example arose from a case study from the mobile phones domain: GoPhone – A Software Product Line in the Mobile Phone Domain1. Based on a software case for the mobile phone product line “GoPhone Elegance”, which is an advanced device, a further software case is sliced out of it. The “GoPhone Elegance” mobile phone is able to receive and display messages with multiple content (text, pictures, sound). For the partial software case it is assumed that a requirement stating that a user must be able to set the recipient of a SMS message shall be reused. Thus, this requirement serves as slicing criterion. Table 5.4 shows an excerpt of the software case for the “GoPhone Elegance” for the messaging part only. Table 5.5 describes the partial software case for the “SetSMSRecipient” functionality. 1http://www.software-kompetenz.de/?21618 IST-2006-033596 ReDSeeDS: Requirements Driven Software Development System page 25 Software Case Marking Language Definition – D4.3 Partial software cases ver. 1.01 21.11.2007 ABSTRACTION LAYER CONTENTSION LAYER CONTENTS Requirements . . . RequirementsPackageMessaging Requirement HandleEMails: The system must be able to handle e-mails. Requirement HandleSMSMessages: The system must be able to handle SMS-messages. RequirementHandleMMSMessages: The systemmust be able to handle MMS-messages. . . . Requirement SetSMSRecipient: The user must be able to set the recipient of a SMS-message. . . . Architecture No architectural relevant information for ’Messaging’ Design see picture 5.4 Code see Listing 5.1 Table 5.4: Excerpt of the software case for the product “GoPhone Elegance”. Consider that those issues related to multimedia-based message content are not adopted in the new software case. Figure 5.5 shows an excerpt of the abstract syntax graph for the messaging part of the “GoPhone Elegance” software case, including the partial software case which is sliced from it. Starting from the slicing criterion illustrated by the Requirement with the thick border, the application of the approach described in section 5.2 results in the partial software case indicated by the cloloured elements. Figure 5.4: Design of the GoPhone Elegance messaging functionality IST-2006-033596 ReDSeeDS: Requirements Driven Software Development System page 26 Software Case Marking Language Definition – D4.3 Partial software cases ver. 1.01 21.11.2007 Listing 5.1: Code for the messaging functionality of “GoPhone Elegance” 1 public abstract class Message { 2 3 public final static String SMS = "SMS"; 4 public final static String MMS = "MMS"; 5 public final static String EMAIL = "EMS"; 6 protected String _recipient = ""; 7 protected String _content = ""; 8 protected String msgType = null; 9 protected int[] maxSize = {0, 0, 0}; 10 11 public Message(String msg) { 12 for (int i = 0; i <= msg.length(); i++) { 13 if (msg.charAt(i) == ’R’) { 14 int recLength = Integer.parseInt(msg.substring(0, i)); 15 i++; 16 _recipient = msg.substring(i, (i + recLength)); 17 msg = msg.substring(i + recLength); 18 break; 19 } 20 } 21 for (int i = 0; i <= msg.length(); i++) { 22 if (msg.charAt(i) == ’C’) { 23 int conLength = Integer.parseInt(msg.substring(0, i)); 24 i++; 25 _content = msg.substring(i, (i + conLength)); 26 break; 27 } 28 } 29 } 30 31 public String getRecipient() { 32 return _recipient; 33 } 34 35 [...] 36 } 37 38 public class SMSMessage extends Message { 39 public SMSMessage() { 40 super(); 41 msgType = Message.SMS; 42 maxSize[0] = 25; 43 maxSize[1] = 160; 44 } 45 46 [...] 47 } 48 49 public class MMSMessage extends Message { 50 // Name of the image file. 51 private String _image = ""; 52 53 public MMSMessage() { 54 super(); 55 msgType = Message.MMS; 56 maxSize[0] = 25; 57 maxSize[1] = 500; 58 } IST-2006-033596 ReDSeeDS: Requirements Driven Software Development System page 27 Software Case Marking Language Definition – D4.3 Partial software cases ver. 1.01 21.11.2007 59 60 [...] 61 } 62 63 public class EMailMessage extends Message { 64 65 private String _subject = ""; 66 private Vector _attachementList = new Vector(); 67 68 public EMailMessage() { 69 super(); 70 msgType = Message.EMAIL; 71 maxSize[0] = 35; 72 maxSize[1] = 70; 73 maxSize[2] = 1000; 74 } 75 76 [...] 77 } IST-2006-033596 ReDSeeDS: Requirements Driven Software Development System page 28 Software Case Marking Language Definition – D4.3 Partial software cases ver. 1.01 21.11.2007 Figure 5.5: Abstract syntax graph for the “GoPhone Elegance” software case excerpt in 5.4 including a partial software case. For the sake of clarity, some elements, e.g. RequirementRepresentations, Operations, etc. are omitted. IST-2006-033596 ReDSeeDS: Requirements Driven Software Development System page 29 Software Case Marking Language Definition – D4.3 Partial software cases ver. 1.01 21.11.2007 ABSTRACTION LAYER CONTENTS Requirements RequirementsPackageMessaging Requirement HandleSMSMessages: The system must be able to handle SMS-messages. Requirement SetSMSRecipient: The user must be able to set the recipient of a SMS-message. Architecture No architectural relevant information for ’Messaging’ Design see picture 5.6 Code see Listing 5.2 Table 5.5: Partial software case on the basis of the Requirement “SetSMSRecipient”ION LAYER CONTENTS Requirements RequirementsPackageMessaging Requirement HandleSMSMessages: The system must be able to handle SMS-messages. Requirement SetSMSRecipient: The user must be able to set the recipient of a SMS-message. Architecture No architectural relevant information for ’Messaging’ Design see picture 5.6 Code see Listing 5.2 Table 5.5: Partial software case on the basis of the Requirement “SetSMSRecipient” Figure 5.6: Design part of the partial software case on the basis of the Requirement “SetSMSRecipient” Listing 5.2: Reused Code 1 public abstract class Message { 2 3 protected String _recipient = ""; 4 protected String _content = ""; 5 protected int[] maxSize = {0, 0, 0}; 6 7 public Message(String msg) { 8 for (int i = 0; i <= msg.length(); i++) { 9 if (msg.charAt(i) == ’R’) { 10 int recLength = Integer.parseInt(msg.substring(0, i)); 11 i++; 12 _recipient = msg.substring(i, (i + recLength)); 13 msg = msg.substring(i + recLength); 14 break; 15 } 16 } 17 for (int i = 0; i <= msg.length(); i++) { 18 if (msg.charAt(i) == ’C’) { 19 int conLength = Integer.parseInt(msg.substring(0, i)); 20 i++; 21 _content = msg.substring(i, (i + conLength)); 22 break; 23 } IST-2006-033596 ReDSeeDS: Requirements Driven Software Development System page 30 Software Case Marking Language Definition – D4.3 Partial software cases ver. 1.01 21.11.2007 24 } 25 } 26 27 public String getRecipient() { 28 return _recipient; 29 } 30 31 [...] 32 } 33 34 public class SMSMessage extends Message { 35 public SMSMessage() { 36 super(); 37 msgType = Message.SMS; 38 maxSize[0] = 25; 39 maxSize[1] = 160; 40 } 41 42 [...] 43 } IST-2006-033596 ReDSeeDS: Requirements Driven Software Development System page 31 Software Case Marking Language Definition – D4.3 Visualisation of differences ver. 1.01 21.11.2007 Chapter 6 Visualisation of differences After the identification of similar requirements in a past software case, these results must be presented to the ReDSeeDS user. More precisely, the requirements specification of the current software and its counterpart in the past software case have to be juxtaposed in order to allow the user to check the outcome of the automatic similarity mapping. Then he could decide on manually discarding requirements from the computed set or on including requirements not yet taken into account. Based on the final set of requirements selected for reuse, a partial software case has to be computed and its contained elements and relationships presented to the user. After an introduction to existing visualisation approaches in section 6.1, section 6.2 describes how to visualise differences between requirements. Section 6.3 deals with the visualisation of partial software cases. 6.1 Known approaches Similarity calculation, its algorithms and visualisation approaches are known at least since the Unix diff-tools in the early 1970s. Since then, various other approaches were published. This section gives an overview about different visualisation strategies rather than about concrete algorithms. Besides the strategy used by the diff tool and its successors to display the difference as a sequence of edit operations, there are also strategies which display the difference in a format more convenient for the user. IST-2006-033596 ReDSeeDS: Requirements Driven Software Development System page 32 Software Case Marking Language Definition – D4.3 Visualisation of differences ver. 1.01 21.11.2007 6.1.1 Integrated parallel visualisation One of those approaches is called (integrated) parallel visualisation. Both documents are displayed in a separate view and the differences and similarities are highlighted using different colours. Figure 6.1 shows a small example. The classes named Class1 and Class3 are part of both models while class Class2 is only part of the first model and Class4 is only part of the second model. The colours green and red are used to visualise the elements that are deleted in the right model or that are added in the right model relative to the left model. Another variant of the integrated parallel visualisation is the tabular view. Figure 6.2 shows a small example of the tabular view of the two models depicted in figure 6.1.